Skip to content

IGNITE-28819 Thin client implementation extraction#13306

Open
nizhikov wants to merge 110 commits into
apache:masterfrom
nizhikov:IGNITE-28819
Open

IGNITE-28819 Thin client implementation extraction#13306
nizhikov wants to merge 110 commits into
apache:masterfrom
nizhikov:IGNITE-28819

Conversation

@nizhikov

Copy link
Copy Markdown
Contributor

Thank you for submitting the pull request to the Apache Ignite.

In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:

The Contribution Checklist

  • There is a single JIRA ticket related to the pull request.
  • The web-link to the pull request is attached to the JIRA ticket.
  • The JIRA ticket has the Patch Available state.
  • The pull request body describes changes that have been made.
    The description explains WHAT and WHY was made instead of HOW.
  • The pull request title is treated as the final commit message.
    The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • A reviewer has been mentioned through the JIRA comments
    (see the Maintainers list)
  • The pull request has been checked by the Teamcity Bot and
    the green visa attached to the JIRA ticket (see tab PR Check at TC.Bot - Instance 1 or TC.Bot - Instance 2)

Notes

If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.

nizhikov and others added 30 commits June 25, 2026 16:48
Create empty modules/thin-client/impl (ignite-thin-client-impl) for the
thin client implementation extraction. It depends only on ignite-commons,
ignite-binary-api and ignite-thin-client-api (no ignite-core dependency).

Wire it into the reactor (root pom.xml), the BOM dependency management,
and ignite-core (compile dependency + maven-shade include) so the module's
classes are bundled back into ignite-core.jar for binary compatibility,
mirroring ignite-thin-client-api.

Exclude ignite-thin-client-impl from the assembly dependency sets
(dependencies-apache-ignite{,-lgpl,-slim}.xml) as done for
ignite-thin-client-api, since the classes ship inside ignite-core.jar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of the first leaf class of the thin
client implementation. ProtocolVersion has no dependencies on ignite-core
internals and is referenced only from within the thin client package, so
it moves cleanly. Its class still ships in ignite-core.jar via the shade
of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. BinaryNameMapperMode has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientCacheEntry has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientConnection has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…impl

Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientConnectionStateHandler has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientJCacheAdapter has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ent-impl

Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientJCacheEntryListenerAdapter has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientMessageDecoder has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientMessageHandler has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientNotificationType has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientProtocolError has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…impl

Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientRetryPolicyContextImpl has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. IgniteClientFutureImpl has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. NotificationListener has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ProtocolVersionFeature has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. QueryPager has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientConnectionMultiplexer has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ient-impl

Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientInternalBinaryConfiguration has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientOperation has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientQueryCursor has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. FieldsQueryPager has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ProtocolContext has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pure relocation (no code change) of a leaf class of the thin client
implementation. ClientFieldsQueryCursor has no ignite-core internal dependencies and is
referenced only from within the thin client package. Its class still
ships in ignite-core.jar via the shade of ignite-thin-client-impl.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientServiceDescriptorImpl's only ignite-core dependency was the import of
org.apache.ignite.services.Service, used solely in a javadoc {@link}. Per the
move convention, the javadoc-only import is removed (the {@link Service} text
remains; doclint is disabled so it does not fail the build), leaving the class
free of ignite-core internals. Relocated to ignite-thin-client-impl; its class
still ships in ignite-core.jar via the shade.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate the ClusterNodeFunc utility class from ignite-core to ignite-commons
so it is available to modules that must not depend on ignite-core (the thin
client implementation being extracted uses ClusterNodeFunc.eqNodes). The class
keeps its package org.apache.ignite.internal.util.lang, so all existing
ignite-core call sites are unaffected.

ClusterNodeFunc references four node-id predicates that lived in ignite-core
(ContainsNodeIdsPredicate, EqualsClusterNodeIdPredicate, HasEqualIdPredicate,
HasNotEqualIdPredicate); they depend only on ignite-commons classes
(ClusterNode, S, IgnitePredicate) and are moved alongside it (keeping their
gridfunc package). EqualsUuidPredicate already lives in ignite-commons.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientClusterNodeImpl's only ignite-core dependency was the static import of
ClusterNodeFunc.eqNodes, now resident in ignite-commons. All its other
dependencies (ClusterNode, ClusterMetrics, S, IgniteProductVersion) already
live in ignite-commons, so this is a pure relocation with no code change. The
class still ships in ignite-core.jar via the shade.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate the SSL context factory classes (SslContextFactory,
AbstractSslContextFactory, DelegatingSSLContextSpi, SSLContextWrapper,
SSLServerSocketFactoryWrapper, SSLSocketFactoryWrapper and package-info) from
ignite-core to ignite-commons so they are available to modules that must not
depend on ignite-core. The thin client implementation being extracted uses
SslContextFactory.DFLT_STORE_TYPE / DFLT_KEY_ALGORITHM.

The package org.apache.ignite.ssl is preserved, so all existing call sites
(configuration classes, discovery/communication SPIs, etc.) are unaffected.
The package's only external dependencies are IgniteException and the A
argument-check helper, both already in ignite-commons.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ClientSslUtils's only ignite-core dependencies were the static imports of
SslContextFactory.DFLT_STORE_TYPE / DFLT_KEY_ALGORITHM, now resident in
ignite-commons. Its other dependencies (SslMode, SslProtocol,
ClientConfiguration) already live in ignite-thin-client-api, so this is a pure
relocation with no code change. The class still ships in ignite-core.jar via
the shade.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Relocate AffinityTopologyVersion from ignite-core to ignite-commons so it is
available to modules that must not depend on ignite-core. The thin client
channel abstraction (ClientChannel#serverTopologyVersion) returns it. The class
is a self-contained value type whose only external dependency (the S
to-string helper) already lives in ignite-commons; its package
org.apache.ignite.internal.processors.affinity is preserved so all existing
call sites are unaffected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
nizhikov and others added 27 commits June 30, 2026 01:12
Relocate the self-contained FastSizeDeque (package org.apache.ignite.util.deque)
from ignite-core to ignite-commons. It is used by GridSelectorNioSessionImpl in the
NIO engine that will move to ignite-nio; it has no ignite-core dependencies of its
own. Binary compatibility is preserved via the maven-shade bundling of
ignite-commons into ignite-core.jar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…her to ignite-commons

Relocate the GridWorker base class together with the WorkProgressDispatcher
interface it implements and the GridWorkerListener it references (all package
org.apache.ignite.internal.util.worker) from ignite-core to ignite-commons. These
form the worker-thread foundation used by the NIO engine (GridNioServer) that will
move to ignite-nio. GridWorker's three U calls (currentTimeMillis/error/warn) are
repointed to their ignite-commons CommonUtils equivalents. GridWorkerFuture and
GridWorkerPool are not referenced by GridWorker and remain in ignite-core. Binary
compatibility is preserved via the maven-shade bundling of ignite-commons into
ignite-core.jar.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mons

Move Scope, SpanStatus, SpanType, Span, SpanManager, NoopSpan, SpanTags and MTC
to ignite-commons, and add NoopSpanManager (no-op SpanManager). GridNioServer
now uses SpanManager/NoopSpanManager instead of Tracing/NoopTracing, removing its
dependency on the core tracing manager. NoopTracing extends NoopSpanManager.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rver from TraceableMessagesTable

Add traceName(Message) to SpanManager: GridTracingManager delegates to
TraceableMessagesTable.traceName, NoopSpanManager returns null. GridNioServer now
calls tracing.traceName(msg) instead of the static TraceableMessagesTable.traceName,
removing its last dependency on core tracing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…NioServer uses CommonUtils

Move sleep(long), cancel(GridWorker), cancel(Iterable), join(GridWorker, log),
join(Iterable, log) and newThread(GridWorker) from IgniteUtils to CommonUtils
(commons). IgniteUtils still inherits them via CommonUtils, so existing U.* callers
are unaffected. GridNioServer now calls CommonUtils instead of U, removing its
dependency on core IgniteUtils.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…nd DFLT_IO_BALANCE_PERIOD to IgniteCommonsSystemProperties; GridNioServer uses IgniteCommonsSystemProperties

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…uration references it (public API constant kept)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ite-commons

Introduce ExpectedFailure marker in ignite-commons so GridCompoundFuture
can classify benign failures without referencing core exception types.
ClusterTopologyCheckedException, IgniteConsistencyViolationException,
IgniteTxOptimisticCheckedException and IgniteFutureCancelledCheckedException
implement it. Failure-handling behavior is preserved.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…LongAdderMetric

Capture the byte-count metrics as bound method references (longAdderMetric(...)::add)
and the outbound queue size as longAdderMetric(...)::value, removing the direct
dependency on LongAdderMetric. No boxing and no per-call allocation, so the hot path
is unaffected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…stead of MetricRegistryImpl

Move metric creation to the GridNioServer call site and pass the queue-size and
max-queue-size metrics as bound method references (longAdderMetric(...)::add,
maxValueMetric(...)::update). Removes LongAdderMetric, MaxValueMetric and
MetricRegistryImpl from the session. increment()/decrement()/add()/update()
become accept(1)/accept(-1)/accept(n), preserving behavior.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ry, drop GridNioServer.outboundMessagesQueueSize()

The size is read in a single place (TcpCommunicationSpi.getOutboundMessagesQueueSize),
which already has the communication metric registry via TcpCommunicationMetricsListener.
Expose it there and delegate from the SPI, removing the LongSupplier metric and the
read method from GridNioServer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ioServer fields

The outbound and max queue-size metrics were rebuilt from the registry on every
session creation; since the metric names are constant the registry returns the same
instance, so cache them once as final LongConsumer fields in the constructor and pass
them to each session. Removes the last reads of the mreg instance field, so the field
is dropped (mreg remains only as a constructor parameter and in the Builder).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move metric registration out of GridNioServer into the callers via IgniteUtils
helpers: setNioServerMetrics (byte counters + queue-size consumers),
registerSslEnabledMetric (SslEnabled gauge) and registerActiveSessionsMetric
(ActiveSessionsCount gauge, backed by the new GridNioServer.activeTcpSessionsCount).
GridNioServer no longer references the metric registry: the mreg constructor
parameter, Builder field and metricRegistry() setter are removed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ry-api and shared types to ignite-commons

Move MessageFactory, MessageReader, MessageWriter and MessageSerializer to
ignite-binary-api (they reference IgniteUuid/CacheObject/KeyCacheObject which live
there). Move the shared MessageType, MessageCollectionItemType, MessageArrayType,
MessageCollectionType, MessageMapType enums and GridLongList to ignite-commons, and
relocate EMPTY_LONGS from IgniteUtils to CommonUtils (still inherited by IgniteUtils).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add the ignite-binary-api dependency to the ignite-nio module so the communication
Message API (MessageFactory/Reader/Writer/Serializer, now in binary-api) is visible
to NIO classes that will be moved into this module.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…age via marker interfaces

Introduce two marker interfaces in ignite-commons: MessageContainer (a message that
wraps another message, implemented by GridIoMessage) and SelfSerializingMessage (a
message that serializes itself directly to a ByteBuffer, implemented by ClientMessage).
GridNioServer now references the markers instead of the concrete core message classes,
removing its last cross-module core dependencies (only same-package nio types remain).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…to IgniteCommonsSystemProperties

Relocate the property and its DFLT_NIO_RECOVERY_DESCRIPTOR_RESERVATION_TIMEOUT default to
IgniteCommonsSystemProperties; GridNioRecoveryDescriptor uses IgniteCommonsSystemProperties,
removing its IgniteSystemProperties dependency.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ADER/writeFully/bytesEqual to CommonUtils

Relocate IGNITE_HEADER, writeFully(SocketChannel,ByteBuffer) and bytesEqual(...) from
IgniteUtils to CommonUtils (still inherited by IgniteUtils) and repoint the nio package
classes from U to CommonUtils, removing their dependency on core's typedef U.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Its only core tie was an @see CIX2 javadoc reference; drop it (F.wrap is inherited from
commons GridFunc) and move the class to ignite-commons so the NIO communication clients
no longer depend on a core type for it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…n to ignite-commons

GridWorkerPool uses CommonUtils.cancel/join (already in commons) instead of U, and the
ComputeExecutionRejectedException it throws moves to ignite-commons as well (FQN preserved).
Removes GridNioAsyncNotifyFilter's dependency on a core worker-pool type.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…r uses SpanManager

Move the self-contained SpanTransport marker interface to ignite-commons and retype
GridNioTracerFilter's tracer to SpanManager (serialize/create are SpanManager methods),
defaulting to NoopSpanManager. Removes the filter's Tracing/NoopTracing/SpanTransport
core dependencies.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…Manager

Pass the SpanManager from GridNioServer into the session and resolve trace names through
SpanManager.traceName instead of the static TraceableMessagesTable.traceName, removing the
session's dependency on the core TraceableMessagesTable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ricRegistryImpl

Retype the filter's handshake-duration metric to LongConsumer and the rejected-sessions
counter to Runnable; metric creation moves to a new IgniteUtils.sslFilter(...) factory that
the four construction sites now call. Removes GridNioSslFilter's dependency on
MetricRegistryImpl/HistogramMetricImpl/IntMetricImpl.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cpCommunicationSpi

Type the reader as MessageReader (setBuffer/reset suffice, the DirectMessageReader cast was
redundant) and inline the 2-byte direct-type decoding instead of using
TcpCommunicationSpi.makeMessageType.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Relocate GridNioServer and the entire org.apache.ignite.internal.util.nio package (39
classes, including the ssl subpackage) from ignite-core to the ignite-nio module, now that
the package depends only on ignite-commons, ignite-binary-api and ignite-grid-unsafe. Add
the ignite-grid-unsafe dependency to ignite-nio. ignite-core continues to depend on
ignite-nio, so all existing references resolve.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ite-thin-client-impl

With the NIO package now in ignite-nio, add an ignite-nio dependency to ignite-thin-client-impl
and move the last 11 thin-client implementation classes (TcpIgniteClient, TcpClientCache,
ReliableChannelImpl, ClientServicesImpl, the continuous-query/listener classes and the
client-side gridnioserver multiplexer/connection/parser/listener) out of ignite-core.
GridNioClientConnectionMultiplexer builds its SSL filter directly (no metrics) instead of via
the core IgniteUtils.sslFilter factory. ignite-core keeps a compile dependency on
ignite-thin-client-impl, so Ignition and platform-client references still resolve.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jul 1, 2026

Copy link
Copy Markdown

Possible compatibility issues. Please, check rolling upgrade cases

This PR modifies protected classes (with Order annotation).
Changes to these classes can break rolling upgrade compatibility.

Affected files:

  • modules/commons/src/main/java/org/apache/ignite/internal/processors/cache/version/GridCacheVersion.java
  • modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoMessage.java
  • modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheReturn.java
  • modules/core/src/main/java/org/apache/ignite/internal/processors/cache/version/GridCacheVersion.java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant